[Chapter 5] 5.4 The Internet Daemon
Author: Craig Hunt
Date: 1999-02-04T01:33:42Z

#

| Chapter 5 Basic Configuration |

## 5.4 The Internet Daemon

The kernel configuration brings the basic transport and IP datagram services of TCP/IP into UNIX. But there is much more to the TCP/IP suite than just the basic services. How are these other protocols included in the UNIX configuration?

Some protocols are explicitly started by including them in the boot files. This technique is used, for example, to start the Routing Information Protocol (RIP) and the Domain Name Service (DNS). The daemons that service these protocols, routed and named respectively, are run from a startup file such as /etc/rc.d/rc.inet2 on a Linux system or /etc/init.d/inetsvc and /etc/init.d/inetinit on a Solaris system. [8]

> [8] Your system may not use these startup files, but startup files are usually located under the /etc directory and often have names that contain rc or init.

Many other network daemons are not started individually. These daemons are started by a server that listens for network service requests and starts the appropriate daemon to process the request. This server is called the internet daemon.

The internet daemon - inetd (pronounced "i net d") - is started at boot time from an initialization file such as /etc/rc.d/rc.inet2. When it is started, inetd reads its configuration from the /etc/inetd.conf file. This file contains the names of the services that inetd listens for and starts. You can add or delete services by making changes to the inetd.conf file.

An example of a file entry is:

>     ftp  stream  tcp  nowait  root  /usr/sbin/in.ftpd   in.ftpd

The fields in the inetd.conf entry are, from left to right:

name

  The name of a service, as listed in the /etc/services file. In the sample entry, the value in this field is `ftp`.

type

  The type of data delivery service used, also called socket type. The commonly used socket types are:

  stream

    The stream delivery service provided by TCP; i.e., TCP byte stream.[9]

    > [9] Here the reference is to TCP/IP sockets and TCP streams - not to AT&T streams I/O or BSD socket I/O.

  dgram

    The packet (datagram) delivery service provided by UDP

  raw

    Direct IP datagram service

  The sample shows that FTP uses a stream socket.
protocol

  This is the name of a protocol, as given in the /etc/protocols file. Its value is usually either "tcp" or "udp." The FTP protocol uses TCP as its transport layer protocol, so the sample entry contains `tcp` in this field.

wait-status

  The value for this field is either "wait" or "nowait." Generally, but not always, datagram type servers require "wait," and stream type servers allow "nowait." If the status is "wait," inetd must wait for the server to release the socket before it begins to listen for more requests on that socket. If the status is "nowait," inetd can immediately begin to listen for more connection requests on the socket. Servers with "nowait" status use sockets other than the connection request socket for processing; i.e., they use dynamically allocated sockets.

uid

  The uid is the username under which the server runs. This can be any valid username, but it is normally root. There are two common exceptions. The finger service often runs as the user nobody or daemon for security reasons, and the uucp service is sometimes run as the user uucp to save space in the system's accounting files.

server

  This is the full pathname of the server program started by inetd. Because our example is from a Solaris system, the path is /usr/sbin/in.ftpd. On your system the path may be different. It is more efficient for inetd to provide some small services directly than it is for inetd to start separate servers for these functions. For these small services, the value of the server field is the keyword "internal," which means that this service is an internal inetd service.

arguments

  These are any command-line arguments that should be passed to the server program when it is invoked. This list always starts with `argv[0]` (the name of the program being executed). The program's manpage documents the valid command-line arguments for each program. In the example only `in.ftpd`, the server's name, is provided.

There are a few situations in which you need to modify the inetd.conf file. For example, you may wish to disable a service. The default configuration provides a full array of servers. Not all of them are required on every system, and for security reasons you may want to disable non-essential services on some computers. To disable a service, place a `#` at the beginning of its entry (which turns the line into a comment) and pass a hang-up signal to the inetd server. When inetd receives a hang-up signal, it re-reads the configuration file and the new configuration takes effect immediately.

You may also need to add new services. We'll see some examples of that in later chapters. Let's look in detail at an example of restoring a service that has been previously disabled. We'll begin by looking at the contents of an /etc/inetd.conf file:

>     # @(#)inetd.conf 1.17 88/02/07 SMI
>     ftp     stream  tcp  nowait  root  /usr/sbin/in.ftpd    in.ftpd
>     telnet  stream  tcp  nowait  root  /usr/sbin/in.telnetd in.telnetd
>     shell   stream  tcp  nowait  root  /usr/sbin/in.rshd    in.rshd
>     login   stream  tcp  nowait  root  /usr/sbin/in.rlogind in.rlogind
>     exec    stream  tcp  nowait  root  /usr/sbin/in.rexecd  in.rexecd
>     finger  stream  tcp  nowait  root  /usr/sbin/in.fingerd in.fingerd
>     #tftp dgram udp wait root /usr/sbin/in.tftpd in.tftpd -s /tftpboot
>     comsat  dgram   udp  wait    root  /usr/sbin/in.comsat  in.comsat
>     talk    dgram   udp  wait    root  /usr/sbin/in.talkd   in.talkd
>     name    dgram   udp  wait    root  /usr/sbin/in.tnamed  in.tnamed
>     daytime stream  tcp  nowait  root    internal
>     time    stream  tcp  nowait  root    internal
>     echo    dgram   udp  wait    root    internal
>     discard dgram   udp  wait    root    internal
>     time    dgram   udp  wait    root    internal

This part of the file shows several standard TCP/IP services. One of these, tftp, is commented out. The TFTP protocol is a special version of FTP that allows file transfers without username/password verification. Because of this, it is a possible security hole and is often disabled in the inetd.conf file.

As an example of modifying the inetd.conf file, we'll reconfigure the system to provide tftp service, which is sometimes necessary for supporting diskless devices. First, use your favorite editor to remove the comment (#) from the tftp entry in inetd.conf. (The example uses sed, everyone's favorite editor!) Then find out the process ID for inetd and pass it the SIGHUP signal. The following steps show how this is done on peanut:

>     # cd /etc
>     # mv inetd.conf inetd.conf.org
>     # cat inetd.conf.org | sed s/#tftp/tftp/ > inetd.conf
>     # ps -acx | grep inetd
>       144 ?  I     0:12 inetd
>     # kill -HUP 144

In some situations, you may also need to modify the pathname of a server or the arguments passed to a particular server when it is invoked. For example, look again at the tftp entry. This line contains command-line arguments that are passed to the tftp server when it is started. The -s /tftpboot option addresses the most obvious tftp security hole. It prevents tftp users from retrieving files that are not located in the directory specified after the -s option. If you want to use another directory for tftp, you must change the inetd.conf file. The only command-line arguments passed to servers started by inetd are those defined in the inetd.conf file.

Security is one of the most important reasons for modifying the inetd.conf file. inetd.conf is used to implement access control through the wrapper program tcpd. The wrapper program replaces the server program in the server field of the inetd.conf entry. Then when inetd hears a connection request on the port, it starts tcpd instead of the application server. tcpd can then enforce extra security before it starts the application server. How to use the wrapper program for access control is covered in Chapter 12.

5.3 The BSD Kernel Configuration File |  | 5.5 Summary